Greg Detre
Friday, November 08, 2002
see paper scribbles about project presentations
you want to build so that you can scale, and so that it can last, through
many changes
doesn't necessarily make sense for the senior person in the pair to do the
typing
top-design is risky when you're building a kind of thing you've never built
before, because your pieces may not fit together
bottom-up design - where there are pieces you know you need - v effective for building unfamiliar types of system - starting from "i know i need this interface" ...
what am i learning about what needs to be in the next layer up?
information-hiding - if there's something that's likely to change,
it should affect the fewest number of other components
if you were to change languages, how much of the Lua-specific syntax has leaked into the rest of the system?
abstract data-types
sets � empty, union, intersection, complement, member, singleton, symmetric difference, insert/remove, forAll, thereExists, filter, map, choice
probably don�t need both singleton and insert
lists
tables
structs
the hard part is getting the right data structures - then the algorithms are easy
if you give me your data structures, i can probably figure out what your code does, but not vice versa
prototyping
start with one query and make it work � cheat flagrantly
write down your example in executable form, as a test
CVS, RCS � you want it to be so that you can make a change and see how it affects performance of the entire system on all the tests
an interface is an agreement about how the software is going to work, and the best way to define an interface is in terms of an example
don�t wait till the end to test
interfaces
never design an interface alone
see an interface as a contract between programmers in a group � in which case, you want to minimise your obligations
these techniques are about being able to answer: when there�s a bug, which side of the interface is it on?
prolog � no static type checking
make sure that you�re able to check that you have a well-formed �what� query (is x a movie, and y a director, as expected?)
whose responsibility is it to provide a given guarantee?
checked run-time error (can be expensive) vs unchecked run-time error (avoiding badly-formed queries is up to the clients, maybe requiring checking on the client-side interface)
C code
who�s responsible for allocating/freeing memory?
conventions for indentations, line breaks and naming variables
when you break things into pair-sized pieces, do you overlap the pairs?
that can make things more complicated
maybe meet less with the whole group, but in pairs